Fix/order acceptance consistency - #693
Conversation
| val current = orderBooks[pairKey] | ||
|
|
||
| if (current !== expected) { | ||
| return false |
There was a problem hiding this comment.
Should we here throw exception or return false? in OrderCommandProcessor#L53 the output of replace is discarded and recovery is only triggered when an exception is throw.
prepared.stateTransition?.let { transition -> try { orderBookStore.replace( pairKey = pairKey, expected = currentBook, replacement = transition.preparedBook ) } catch (exception: Throwable) { recoveryManager.enterRecovery( cause = exception, pair = command.pair, expectedSequence = transition.nextSequence ) ...
| prepared: PreparedCommandResult, | ||
| inputMetadata: InputKafkaMetadata | ||
| ) { | ||
| check(kafkaTemplate.isTransactional) { |
There was a problem hiding this comment.
Do we have a transactional KafkaTemplate bean? As I can see in EventsKafkaConfig#L25 that no "transaction.id" config is passed.
There was a problem hiding this comment.
You are right, I forgot to add my changed configuration file : ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG to true,
ProducerConfig.RETRIES_CONFIG to 10,
ProducerConfig.DELIVERY_TIMEOUT_MS_CONFIG to 5000,
ProducerConfig.REQUEST_TIMEOUT_MS_CONFIG to 5000,
ProducerConfig.TRANSACTIONAL_ID_CONFIG to "matching-engine-tx"
| val afterSnapshot = | ||
| workingBook.snapshot() | ||
|
|
||
| // We will implement this part next. |
There was a problem hiding this comment.
What is this missing next step?
There was a problem hiding this comment.
The missing next step is to compare the before and after order book snapshots and generate a delta containing only the changed state, instead of publishing the complete after-snapshot for every command. This optimization should reduce message size and improve Kafka/network performance. It has been intentionally postponed so the current full-snapshot approach can first be validated in a simpler and more reliable form.
| logCurrentState() | ||
| } | ||
|
|
||
| override fun handleEditCommand(orderCommand: OrderEditCommand): Order? { |
There was a problem hiding this comment.
It seems handleEditCommand is removed, how can handle editing of an order?
There was a problem hiding this comment.
Our business team has suggested that, from a user-experience perspective, exchanges should use a cancel + create new order flow instead of editing an existing order. We are still discussing and evaluating this decision with the team.
3 participants
No description provided.